-
Notifications
You must be signed in to change notification settings - Fork 68
implement support for Forgejo comments and reactions #906
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
implement support for Forgejo comments and reactions #906
Conversation
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 34s |
|
Please @morucci @lbarcziova i tried to add mergeit label but it seems i don't have the necessary permission. |
LecrisUT
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original issue is about implementation for forgejo please implement it there first 1. The generalisation in the abstract is a more difficult task that requires some refactoring.
Footnotes
recipe.yaml
Outdated
| name: | ||
| - twine # we need newest twine, b/c of the check command | ||
| - readme_renderer[md] | ||
| - pytest-cov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you open a separate PR for this? I think it would be better to drop the default --cov flags and create a separate test environment that would integrate with codecov or such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to rebase onto main. This change has been incorporated in #893 (learning opportunity to get some intuition of what git rebase does and how to handle its conflicts 🙂)
ogr/abstract.py
Outdated
| """Delete a reaction.""" | ||
| raise NotImplementedError() | ||
| if not self._id: | ||
| raise ValueError("Cannot delete a reaction without an ID.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This clashes with reaction_id being optional. If the intent is that id is always present then there should be an overwritable @property with the default being to read self._id or raise.
ogr/abstract.py
Outdated
| raw_reaction: Any, | ||
| reaction_id: Optional[int] = None, | ||
| parent: Optional[Any] = None, | ||
| ) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation would be appreciated. No idea what parent is meant to be.
ogr/abstract.py
Outdated
| self._body = raw_comment["body"] | ||
| self._author = raw_comment["user"]["login"] | ||
| self._created = raw_comment["created_at"] | ||
| self._edited = raw_comment.get("updated_at") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this is a strong assumption. Either make the type-hinting of raw_comment more explicit or let it be overwritten in the actual implementation. Same for the other parts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok thank you am on it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to double check. I am not recommending to tackle type-hinting approach in this PR (maybe in a separate one). Instead you should try to implement it in the /ogr/services/forgejo files first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok i will
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also drop the changes made in abstract.py. I saw you dropped some with a33e90e, but the remaining changes should also be dropped for now.
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 40s |
e7f684e to
93d476d
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 2m 36s |
lbarcziova
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks a lot for having a look into this!
To clarify the code structure, the ogr/abstract.py should not be changed anyhow, it just holds the interface that is then implemented for particular forges in respective directories in ogr/services (e.g. github). So can you please move the implementation here, creating new files? You can check how it is done for other forges e.g. https://github.com/packit/ogr/tree/main/ogr/services/github and also having a look into implementation in ogr/services/forgejo can be helpful. Let me know if this is clear!
| ex: Union[ | ||
| github.GithubException, | ||
| gitlab.GitlabError, | ||
| pyforgejo.core.api_error.ApiError, | ||
| ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe these changes related to exceptions were not intended, or?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, for the unintended change. I'll work on them and push an update. Please hold off on reviewing until I fix it. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this came from when i pull recent changes from the before i pushed to the pr
|
Thank you so much, You mean i should create a file and impliment the logic at https://github.com/packit/ogr/tree/main/ogr/services/forgejo following the examples at https://github.com/packit/ogr/tree/main/ogr/services/github |
|
Hello @lbarcziova i want to create a pr for this implementation but i want to use a new pr altogether. |
|
Generally it is preferred to rebase and continue in the same PR in order to keep the discussion history, but if you feel like you need a fresh start at it, then you can restart it, as long as you do not do it excessively that it would confuse people. To me the discussions so far have been quite minimal and I wouldn't do a fresh start yet (reviews can easily get to ~100 comments and I still go back to those comments every now and then). Instead, you can mark conversations as resolved, and I sometimes mark my own comments when I feel it is outdated. |
|
Ok thank you |
|
Build failed. ✔️ pre-commit SUCCESS in 3m 41s |
afa6147 to
381972a
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 3m 48s |
|
Hello , |
LecrisUT
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest you either try:
- work locally similar to the github example in the readme, but instead use codeberg and for example try to read the reactions on this issue. Or better yet, open up a test repo for you to play with and try the whole read+write api (be a good netizen and don't test write on other people's public repos)
- or see the test-suite and reimplement the github comments tests in the form of the forgejo tests
| forgejo_client: Any, | ||
| repository: str, | ||
| issue_number: int, | ||
| ) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this __init__ come from. I don't see a reference to forgejo_client in the current codebase
Ok let me work on it |
lbarcziova
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having a closer look at the PR, this functionality unfortunately depends a bit on the implementation of the ForgejoPullRequest and ForgejoIssue class. To be able to actually access the comments (=> and reactions), also the get_comment and _get_all_comments need to be implemented for both of them, see example in Gitlab implementation here and here.
| url = ( | ||
| f"{self._forgejo_client.forgejo_url}/api/v1/repos/" | ||
| f"{self._repository}/issues/{self._issue_number}/reactions/{self._id}" | ||
| ) | ||
| self._forgejo_client._make_request("DELETE", url) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we are using the client library methods, see examples here, that file can be an inspiration on how to implement the methods. So for this particular case, you would use this method. And similarly, for other methods where you currently construct the URL manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for this clarity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am working on implementing ForgejoIssue (#896) and it also depends on ForgejoIssueComments, I can collaborate to complete this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @mynk8 will you have time today?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's kind of true, I need ForgejoIssueComments for get_comments and _get_all_comments and this is where I think I can help with here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I missed that this PR is now implementing comments in general. Up to you how it is easier to coordinate. You could also make it a NotImplementedError and follow it up in a subsequent PR. No need to implement everything in a single PR, as long as the minimal functionality can be tested
Implement Support for Forgejo Comments and Reactions
Description:
This PR introduces support for handling comments and reactions within Forgejo. The changes include implementing classes for managing issue comments, pull request comments, commit comments, and their associated reactions. The implementation follows the structure of the existing
ogrframework while integrating Forgejo API functionalities.Changes in this PR:
Created the comments.py file in ogr/services/forgejo
Added
ForgejoReactionclassAdded
ForgejoCommentclassAdded Specialized Comment Classes:
ForgejoIssueComment: Represents comments on issues.ForgejoPRComment: Represents comments on pull requests.ForgejoCommitComment: Represents comments on commits.fixes #883